1. Field of the Invention
This invention generally relates to transmission control protocol (TCP) communications and, more particularly, to a system and method for real-time streaming of media from selected applications, using TCP within a local area network (LAN) or Enterprise network.
2. Description of the Related Art
As noted in U.S. Pat. No. 6,252,851 (Siu et al.), TCP is a connection-oriented transport protocol that is designed to work with any underlying network technology. TCP makes no assumption as to how the network processes the data it sends, and perform its own data recovery and flow control. The TCP acknowledgment-based flow control mechanism is designed to slow down the source rate when the network becomes congested. TCP has no direct way of knowing when the network is congested. It can only indirectly detect congestion by keeping track of how many packets are lost and/or delayed. Packet loss is indicated by a failure to receive the appropriate acknowledgments, depending on the particular TCP variant. When packets do get lost and/or delayed, the loss indicates that some queue in the network might have experienced overflow. When TCP detects a packet loss and/or delay, it reduces its source rate to alleviate the congestion that could have caused the packet loss.
TCP's congestion control and error recovery, based on acknowledgments, are implemented by a dynamic window at the source. Every packet that is sent must be acknowledged by the destination. A congestion window size determines the number of unacknowledged packets that can be present in the network at any given time, and is initially set to one. Each packet includes a sequence number, so that packets arriving at the destination out of order can be reordered. A destination responds to an incoming packet by sending an acknowledgment back to the source. If a sequence number is skipped, the destination continues to return the same sequence number, resulting in duplicate acknowledgments.
In general, when a packet is acknowledged, the congestion window size increases, and when a packet is lost, the window size decreases, forcing the rate to decrease. Specifically, during the “slow-start” phase, the window is incremented by one for each acknowledgment received, so that during this phase, two packets are transmitted for each acknowledgment received, resulting in an additive increase in the packet transmission rate.
After the window reaches some threshold, the “congestion-avoidance” phase is entered, in which the window is incremented by one for every w acknowledgments received, where w is the window size. Thus, in this phase, usually one packet is transmitted for each acknowledgment received, but occasionally (when w is incremented), two packets will be transmitted. Finally, when a maximum limit, or threshold level is reached, the window size does not change, and one packet is released for every acknowledgment received. This is the “saturation” phase. When a packet is lost, the congestion-avoidance threshold is set to one half the window size, and the window is reduced to one.
As noted in U.S. Pat. No. 6,215,769 (Ghani et al.), to manage congestion, TCP uses a sliding window mechanism coupled with reactive congestion control to adjust the sender's window size. The protocol adjusts its transmission behavior contingent to returning acknowledgment (ACK) packets sent from the remote receiver's end. A problem with TCP, however, is that its congestion control mechanism is relatively slow. Most TCP implementations use very coarse timers to measure timeouts, i.e., roughly 200-500 ms granularity. Further, most TCP implementations rely on ACK delays or packet drops to detect congestion. As a result, excessive source window reductions can result in large amounts of bandwidth being wasted as the TCP source is forced to restart its transmission window. Further, many studies have shown that TCP does not perform very well over networks with large propagation delays.
To combat the above shortcomings with TCP, it is necessary to minimize the chances of network congestion by somehow incorporating faster congestion indication mechanisms in the TCP feedback loop. However, to ensure compatibility with current versions and to expedite market acceptance, any such attempt must preclude changes to the actual TCP protocol or its implementation. Along these lines, a variety of ACK pacing schemes have been proposed. These ACK pacing schemes basically modulate the spacing of TCP ACK packets to limit source emissions during periods of congestion. ACK pacing is well-suited at the boundary of high speed (sub)networks, such as ATM, gigabit IP (i.e., optical WDM), or satellite. In essence this technique performs TCP traffic shaping at the access nodes. Such methodologies are specifically beneficial for advanced ATM data services, i.e., underlying ABR flow control or per-connection queuing, where congestion tends to buildup at the periphery of the ATM network, i.e., in the access nodes. If the forward link is congested, as indicated via some congestion metric, ACK packets are appropriately delayed before being sent to the source.
Other authors have proposed modifying fields in the ACK packets themselves, i.e., receiver-window size, to improve performance. However, such schemes either require accurate round-trip delay measurements or cannot maintain tight buffer control. Furthermore, rewriting ACK packet fields requires expensive checksum recomputations. Although ACK pacing is an effective way of controlling TCP source behaviors, many of the proposed schemes are either too complex and/or overly sensitive to network parameter settings. Since studies have shown that TCP's throughput and fairness levels can be low in many high-speed network scenarios, it is necessary to devise efficient, practical schemes to enhance its performance. Although amending the protocol's functionality itself is also an option, this may not be a feasible alternative in the short-to-medium time frame. It is along these lines that the ACK pacing methods can provide significant benefits.
TCP is not conventionally suitable for streaming media applications. This is because it TCP cannot handle time-based media in a very effective manner. However, there are applications where TCP is required for streaming media delivery. For example, a remote desktop protocol (RDP) application running on top of TCP/IP. If a RDP protocol and RDP virtual channel are being used for streaming image and video data, problems can result. The most notable problems concern latency.
To continue the example, a windows NT terminal server can be used to display a Powerpoint presentation at a RDP client. When there is no cross-traffic on the network, it takes approximately 200 milliseconds (ms) to transport data corresponding to a slide. The same slide of data may require 1100 ms to transport when there is competing cross-traffic (which started at a particular time). That is, the latency increases from 200 to 1100 ms. Similarly, video frame dropping may occur when video is “played back” using TCP network. The frame dropping occurs due to missed playout deadlines.
Modifications have been suggested with respect to TCP, with motivation of providing network fairness, while at the same time, increasing throughput. These efforts have resulted in the various congestion avoidance and slow start schemes. In addition, suggestions have been made to modify round trip times, or to include additional fields in the TCP packets. Several of these modifications are aimed at a good performance on the general Internet and on network paths that span multiple routers and one or more bottleneck links. However, none of these proposed solutions is particularly addressed to improving latency in a LAN network.
It would be advantageous if the TCP in a LAN could be modified to improve the latency of at least a small class of higher priority applications.